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n ATA FMPQWERPn T ARORSAVTst ^- Tfrt ARrHTTECTURE 
Inventor: Steven K. BUbling 

FTFT n OF TWF TNVF.NTION 

The present invention relates to test programming methods, and in particular 
to software test programs for multiple test platforms. 

TtAryrrROTTNTD OF ™ TNVENTION 

The realities of the current business environment require test development 
departments having reduced staffs to maintain and support many legacy test programs while 
implement implementing new test programs. Often, each of these test programs will apply to 
multiple software testable line-replaceable unit (LRU) products of a single family and all 
configurations of those LRU products. All together, these legacy and new test programs may 
address both factory and field software test requirements for literally thousands of LRU 
configurations. 

Unfortunately, traditional test development groups are unable to provide the 
needed additional test development and maintenance capability with current or reduced head- 
count, while simultaneously improving test integrity and advancing the feature set of the test 

programs. 

Figure 1 is a block diagram that illustrates a traditional system test architecture 
1 that typically includes a test executive 3, a test program 5, a unit under test (UUT) interface 
7 and a ground support equipment (GSE) interface 9. The UUT and GSE interface with one 
another during test, and the unit-under-test interfaces with the UUT interface 7, while the 
ground support equipment interfaces with the GSE interface 9. The Test Executive 3 outputs 
a test report 11, typically a hard copy in text format. 

As a minimum, the test executive 3 contains an execution engine, which is the 
software responsible for controlling the execution of test sequences. Test executives can be 
purchased as commercial-off-the-shelf software or developed independently. Currently 
commercially available test executive packages contain a variety of features, but most 
provide at least: test sequencing capability; pass/fail analysis capability; an execution control 
that pmvides user sequences, stop-on- fail capability, sequence looping, pause and abort 
capabilities; and a user interface that pennits the user to view the current test, view the 
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current test results, create user execution sequences, and also provides test result reportmg 
and sometimes includes hardware resource management functionality. 

A commercial-off-the-shelf software solution eliminates development and 
maintenance costs. However, the commercial solution requires a run-time license fee per 
tester that may, when used for relatively inexpensive testers, this may represent a high 
relative cost that consumers are not willing to pay. Additionally, the built-in features 
provided by the commercial solution may not meet the project needs, thereby requiring 
disabling or modification of the features. Often, the commercial-off-the-shelf software 
feature-set does not meet the project needs. This requires some type of development and 
maintenance to modify or disable features and to implement the feature via independent 
development. Historically modifications of the commercial software feature-set have 
included: adding different types of pass/fail analysis, modifying the test report content and 
style, extending test result logging to output data in an statistical process control (SPC) 
format, changes to the user interface, and adding fianctionality. Some commercial-off-the- 
shelf software solutions even require a thorough understanding of the test executive's low- 
level architecture to make such changes. 

The commercial-ofiF-the-shelf software solution may also require the test 
project to become dependent on a single vendor for the software maintenance and fiiture 
development. The potential for problems is present anytime a single vendor is used, not the 
least of which is vendor viability. The potential for reduced or discontinued product support, 
whether influenced by marketing or economic pressures, is always present. Since the 
feature-set and user interface are under the vendor's control when a commercial-off-the-shelf 
test executive is relied upon, changes made by the manufacturer during version updates can 
require developer retraining and the test programs to be rewritten. Such vendor changes can 
also affect the existing test program documentation. Changes to the user interface can also 
necessitate operator re-training in product usage. With current globalization test programs are 
used at shops throughout the world so that such re-training causes both the manufacturer and 
the end user to incur higher costs. Therefore, when a commercial-off-the-shelf software 
solution is selected, a product with a large installed-based fi-om a prominent company should 
be used. However, developing the test executive independently can eliminate the problems 

associated with a single vendor. 

The test program 5 performs the actual pass/fail testing of the UUT. In order 
to accomplish this task, the test program must perform UUT and GSE initialization, test 
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i„Ma.,za.io„. stimulus application, response reading and .es. cleanup^ Figure 2 ,us.ra,es ,hat 
in any give. .es,. the .es. « imerftoes with .he UUT and ,he OSE n,uHiple „mes .„ 
obunn response readings, i.e. .es. resutts. based on specific stimuli The GSE in.erfaces are 
usually vmtten .o .he driver level, which is associared wi.h specific hardware A. .he .es, 
level each ,es. is a cus.om .es. .ha. is specific .o ti.e UUT and GSE. As illus.ra.ed. .he .es.s 
i„di<..ed generally a. .3 consis. of in,en„ixed ealls direcly .o .he UUT and GSE hardware 
drivers which causes each .es. .0 be cuslom .0 .he tes. program. Because of such 
.pecializa.ion, .es.s are .ypically no. reusable across UUTs nor OSEs. .herefore a un„ue .es. 
program is required for each .ype of UUT tes.ed 

The UUT inlerface 7 includes a driver .ha. provides access <o .he UUT fi>r 
hardware conttol and for da« reading/writing. A moni.or program, .ypically accessible from 
an RS-232 .emrinal program or E*eme.. wically provides access .o .he UUT hardware. 
Commands are sen, .o *e mom,or .o se. and re«i hardware s.a.es and .o .ransm,. and rece,ve 
da« I. an aircraft environmen,. .his monLor is .ypically par. of fligh. software or .s special 
embedded .es, code such as remo,^access ,es, software (RATS) or hardware bu,l.-.n ,es. 
(HBIT) The UUT teerftce 7 is a computer software configuration i.em (CSCI) .ha. 
i„.erfaces wi.h fligh. code or a manufacwrer's proprie^ry .es. code, such as .he RATS or 
roiT code A srandard UUT imerface is no. cu.ren.ly available for many manufacmrers. bu. 
a s.andard bus access channel may be available for tore LRU produ«s. 

The GSE Inrerface 9 provides access .0 fte OSE hardware tor conttol and for 
dam reading and writing The OSE interface 9 is ano,her computer software confiprration 
hem. typically supplied by a vendor. *a, has no common or s,andard inter6«. Access to 
individual h^dware components varies with difi-eren. manufaCurers and circuh cards ^d .s 
performed via .he driven .ha. are provided by ,he card manufaCurers Obsolescence of a 
component requires a driver change, which in requires a .es. program change. 

Additionally, examination of ,he ttaditional .es. software developmen. process 
exposes shorrcomings in several areas ti». impede rapid .es. program developmen, and 
main,ainabili.y. and may impaC ,he qualhy of ,he finished ,es. program. For examp^, es. 
software 13 is rewritten for each test project and often for each channel of a s,gnal. Tes^s are 
, dependent on specific hardware, and test software is written for application .0 a pamcular 
UUT produc. .ype. Common ,es.s operate differenfly on each .es. projec. and vary m 
oomplceness and rigor This lack of res. commonality also affects the test program 
maintainability. Since all test changes require code modification, and .herefore a stalled 
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softwa« designer, eaoh tes. progran, requires "experrs" so ,ha, development and maintenance 
times are often too long to satisiy project sdtedules. Hardware obsolescence causes exte„s,ve 
code changes, which affects all test pmjects using the obsolete hardware. Even m.nor 
changes to requirements can cause extensive rewriting of the test program. Also, the 
5 traditional software development proc»s is no. easily adaptable to modem mult,-stat,on 
environments such as Highly Accelerated Stress Screening (HASS). 

Use of the above traditional approach to test program development thus ties up 
excessive test development resources. Because of this, several methods have been tried 
throughout industry to overcome the inherent problems with the traditional approach. One 
,0 such approach provides for use of code libraries as a method of software reuse. Another 
approach out-sources test pmgram development to a user's other internal resources, test 
equipment vendors, or generic engineering contractors. 

Though the concept of software code reuse may be effective m some 
instances, the use of code libraries often fails if «rch reuse is no, built into the development 
,5 process Code libraries also require management and tWr use is difficult to enforce with the 
realities of today's overburdened development teams. Often test program developers do not 
know that the code libraries exist, or they feel that the code in the libraries is inferior to what 
they can generate. In either case, the software is often rewritten. 

The use of outsourcing ft>r test programs has been rejected by some product 
20 manufacturers for a number of reasons. One objection is that such outsourcing merely moves 
the shortcomings of the traditional software developmem process ft-om internal development 
organizations to the external contraaor All of the inefficiencies remain, as do the 
maintenance problems. In addition, outsourcing adds a new set of challenges, such as 
contractor management, the need for detailed and formalized test program spcc,f,ca.,ons 
25 deployment of a test platfbr^ and LRU product to tite external site, determining ownersh,p of 
tire finished test program and responsibility fcr maintenance, and maintaining secunty of the 
manufacnirer's proprietary information. 

Successft.1 outsourcing often relies on a Sill time alliance manager for 
interfacing with tite outsource contractor and resolving issues that surftce. Since the 
30 comractor is external, access to the manufacturer's product designers is limited whrch 

requires increased managemem of the specification and design documents to reflect LRU 
product design changes during the development process. In order to aUow the contractor to 
test the test program during development, a complete test platform and VRV product must be 
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preset a. ,h= «,«rac,or-s remote site. Often .his requires the manufacwrer's personnel to 
.ravel .o ,he ren».e si.e for semp or repair of .he hardware Internal n,ain,enance of the code, 
with hs learning curve, ntus. be weighed against eontracor maintenance, which usually has 
update cost and responsiveness problems. Despite confidentiality agreements, deployng 
5 specifications and LRU products to external sites carries the risk of the manufacturer's 

proprie.a,7 information being transfen«i to competitors, this is especially so in the aerospace 
industry given the current level of mergers and acquisitions in the industry. 

While the foregoing provides an outline of the traditional test development 
p^cess and architecture, current test development practices, both those of the Assignee and 
,0 those within the testing industn- in general have advanced the art to produce current test 
program development "best practices" which are discussed immediately below. 

Several items have been developed that have proven effective in reducmg test 
program development time and improving maintainabUity In 1992. reusable software 
components edited for tasks .h« were not directly involved with VUT tesUng and .ha. 
,5 were common acoss all projecs for a user's particular product line. These include pass/fa.l 
analysis and test repon generation. UUT conflguration verification and a common operator 
imerfece. A tester error-logging component was also developed. 

Component commonality of the reusable software components aided the 
user's test designers in performing tes. pmgram maimenance. Designers were now able .o 
20 support multiple projeCs wi.hout a large learning curve. Later, it was recogmzed that th,s 
concept of commonality could be improved by implementing an Accepunce Test Procedure 
(ATP) code framework This ATP code framework provided a template of common 
subroutines and variables to all projects and performed software component initialization and 
cleamtp Development of new projects proceeded more quickly because the test designer no 
25 longer had to create a pn,ject ftom scratch. A stmaure was in place and a large amount of 
code was ah^ady written and was reusable. Test program main.ainabili.y again sigmf,can.ly 
increased because fte .es. program startup. GSE initialization. UUT imtialization. launchmg 
and interftcing to the software components, and test program cleam.p tasks were now 
performed the same way and in the same subroutines across all the user's ATP code 

30 ftamework-based projects 

An unplanned benefit of the ATP code ftamework was the ability to easdy 
implemem SPC data logging on all projects. The pass/fail analyzer software componem was 
upgn^ied, and since all projects used the component and the same subroutines, the .nterftce 



changes were added ,o one projec. and a« AT9 code ftamework-based projects were able .o 

quickly add the same changes. 

As discussed above, software components «ere developed to provide 

non-.est.re.ted capabUH, across test projects. These softw^ Z^^^^^ 
for specific projects bu, were fuUy documented and released as separate CSCls. The pa^s/fa 
nailer and reU8enera.orpe,forms.estpass/,.lana,,sisandwHtes.heresu,.s.o he.es. 

report U. Typically this .Unc.io„ali.y is part ofacommercial-off-.he.shelf.es. «cecut,ve 

"^^^ Commonality was extended to the operator interfece. whereby a componen. 
„aa crea.ed .ha. provided a common looU and feel .o all of the user's .es. p^jecs. Th,s 
componen. was configurable so .1^ .he user's .es. projeC-specific •"^"-"'"^ 
disp ayed to and gathered from users in addition to the standard informa.,o„ When combmed 
1 a common test executive. *e ,es. opera.ors were now able to move betw^n pr ,e«s 
without having .o releam anything about the .es. sys.em^ By using a UUT confl^^ra.,on 
, marrix .ha. is struCred .o lis. all UUI par. numbers and all valid — J 
conflgurafions. all par. numbers are displayed .0 .he user in a drop-down hs. con.rol, .hereb 
lira.i„g .yping errors by .he opera.or. Once a par. number is seleced, .he test program , 
Itousethlnfigurationma^ixmedaU.0 perform vaada.onof.heUUTh.dware and 

softwareconf.^rafi.s^^^__^^^^^^_^^_^_ 

■ aid .o manufacuring in verifying .ha. only valid UUT co,rflgura.io„s are shipped U> 
c„s.ome.^ Ac^rdingly, a .es, .ype value is assigned «. each of a user's produc. 
conflgurarions ,ha. idenUfies hems .ha. would cause the test program to branch or p^ a 
tes. diffe^mly. This iden.ification tonctionality allows the .cs. program .o 

,S fea.ures. r.her .han UUT par. numbers. Thus, as new UUT confi^ra.,ons are add«. no 
changes need .o be made to the test ptogram. Using the test type approach, s.ngle .est 
!Z™sareable.o.es.mu..ipleX^U produc. confi^rations. thereby reducingthen^^^^ 

of CSCIS .ha. mus. be m»n.ained. This file is opfionally main.ained by LRU produ« 
designers, wh^eby tes. designers are removed ft.m software updating when new UUT 

30 ^^^^,^„,„,3,,c.ent^^ 

of time spent maintaining .cs. programs. The lac. of commonalhy in «s. program design and 
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implementation required *e mrimenan* person .o spend considerable time becoming 
familiar vrith the test program in ord« to implement changes 

A second goal of the ATP code S^iework was to provide the software 
designer creating a new test project with a predefined starting place and format. This ,s 
5 especially usefiil for inexperienced programmers. 

Prior to implementation of the ATP code fi™»»orlc different test projects 
often used different subroutines for common tasks. An example is UUI power control 
perform among different test programs, whe« each test program previously used a dtfTeren. 
subroutine name for UUT power control, or used multiple subroutines in the same test 
,0 pro^ to perform this common ft,nction With the ATP code framework. ^1 ««' 

areLctured to control UUT power with the same common subroutine f,„«0™ 
Differences in test platforms may cause implementation of this UUT power control 
subroutine to vary across pn>iects. but maintenance personnel immediately knows where to 

find power control. 

Tables 1 and 2 illustrate the difference between pre- and post-ATP code 
framework code for perfonningUUT power control. TableliUustrates that diff^^^^^ 

are often structured with different subroutines to perform a common task. In the example of 
Table 1, different test projects A, B, C and D use different subroutines for power control so 
that maintenance personnel would need to study each test program to learn how the specific 

20 project performs this task. A common problem with this approach is that maintenance 
persom^el would make necessa^ changes to one subroutine, only to find out later that 
multiple different subroutines are used to control power. The changes would have to be 
duplicated until all power control subroutines were updated for the single test project. 

Table 1, Power Control Before ATP Fr amework 
Project C 



15 



Project A 



25 



Not shown in Table 1 are projects that write directly to the hardware via GPIB 
(general purpose interface bus) or VO commands and do not even use a power control 
subroutine. 
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Table 2 shows that, when the ATP Framework is used, a maintenance 
pro^ammer now always goes to the same subroutine UutPo^er to make power control 
changes. 

Table 2, Power Control Using ATP Framework 




Use of the ATP code framework also ensures that a consistently 
comprehensive test report is generated. Such a report contains common information useful 
for troubleshooting problems remotely or satisfying Quality Assurance (QA) .^.u-rements m 
addition to the test pass/M status. Such information may include: test program sofhvare 
ntodule versions and file dates, times and paths. UUT configuration data, GSE configurafion 
10 and calibration data; and ATP document and revision numbers 

By example and without limitation, in the aerospace industry audns by the 
Federal Aviation Administration (FAA) and customer, repeatedly ask how veriflcat.on ,s 
accomplished that the test progr^n being used is actually .he curremly released software. 
Previously, such verification required performing an examination of the test program Versron 
,5 Description Documem (VDD) and comparing the file dates and times against those on the 
test station The ATP code framework soWes this problem by containing sofhvare module 
verification, which performs a checksum on the test propam software modules and pnnts 
pass/fail status to the test report. 

Different locations where the test program is used, such as product design, 
20 repair centers, the factor, and customer installations, often have different testing inte^ 
and data gathedng requirements. For example, the test pro-am may be designed so that the 
factory ATP contains all tests fcr the UUT, while the ATP for repair and overhaul 
organizations and customer installations is typically a subset of all the factory te^s for the 
UUT The ATP code ftamework includes provisions coMrolled by a senap package, usually 
25 provided on a computer-readable disk or other computer-readable medium, to perform 
differently as a fimction of where the testing is being performed 

Figure 3 is a block diagram of a current state-of-th^art test architecture that 
illustrates the traditional test architeemre incorporating the software components 15a 
(pass/fail analyzer shown); the UUT configuration matrix .7 interftced to U>e ATP code 
30 framework 19 by the operator interface and configuration component of the software 

components l5b; and SPC output 21. As illustrated, the component-based ATP Framework 
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architecture 1 of current test programs has worked effectively to maximize software code 
reuse and to quickly add new features. The component-based ATP code framework 
architecture is also known to effectively permit test project-specific customization. 

Additionally, the test and software industries have been working on 
5 technologies that can make development and maintenance of test programs easier. For 
example a common problem for test development groups is resolving tester hardware 
obsolescence as products age. Changing to new hardware traditionally requires rewrttmg of 
the test program and involves investment of valuable resources. Thus, changmg to new 
hardware can interfere with LRU product production schedules, either directly by shutting 
10 down the production line, or indirectly by tying up resources needed for new test project 

development. Windows NT® developed by Microsoft Corporation is a well-known example 
of hardware independence. By creating a Hardware Abstraction Layer (HAL), Microsoft's 
NT® operating system is able to run on processor chips developed by different 

manufacturers. u T\n 

15 The concept of Interchangeable Virtual Instruments was developed by the IVI 

Foundation (www.mfoundation.org) as an industry initiative to handle hardware 
obsolescence. The IVI Foundation is an open consortium of companies chartered with 
defining software standards for instrument interchangeability. By defining a standard 
instrument driver model that enables engineers to swap instruments without requmng 
20 software changes, the IVI Foundation members believe that significant savings in time and 
money will resuh. Instruments such as oscilloscopes, signal generators, digital multx-meters 
(DMMs) and power supplies currently support this interface. 

ATLAS (Abbreviated Test Language for All Systems)-based test 
specifications and test progr^s are defined by ARINC (Aeronautical Radio Incorporated) 
25 and is also known as ARINC-626. In order to provide an alternative to the ATLAS-based test 
specifications and test programs, the Airlines Electronic Engineering Committee developed 
the ARINC 625-1 specification "Quality Management Process For Test Procedure 
Generation " The ARINC 625-1 specification provides test strategy and a LRU product 
testability description; a UUT description, including connector pin descriptions and Input and 
30 Output (I/O) descriptions; test equipment resource requirements; a test vocabulary; 
predefined functions and procedures; and a detailed test specification. 

ARINC 625-1 defines two separate specifications, the test specification, which 
is a tester independent description of the tests„and the test implementation specification that 
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describe, how .he tes. specification is implemented on specific GSE and provides shop 
verification ofthe test Specification. 

National Instn-ments Company, Inc.® of Baltimore, Maryland, is beheved to 
be the cur^nt industry leader in test hardware and software. Virtual Instrument Standard 
Architecture (VISA) is currently National Instruments' statKlard method of communica.,on 
with communication ports (ComPorts). GPB (general purpose interface bus) devrces. and 
VM (VMEbus extension for Instmmentation) devices. All of these devices use a common 
interface for initialization, reading and writing. Since these devices all have a common 
interface to the test program, .hey can be changed without affeCing .he .est program. ^ 
, National Instruments Data Acquisition (NI-DAQ) is National Instruments 

common interftce to data acquisition devices National Instruments' analog, digital and ttmer 
card drivers have a common set of imerface fimctions. This common se, of mterface 
functions allows the test prog™, to interfece with multiple NI-DAQ cards wi.hou, changes. 

For general test program development. National Instruments provides two 
5 languages, both of which are based on a -vim-al panel,- wherein a vi,.ual panel is a 

collecion of knobs, swiuhes, cha..s and o.her instrument controls displayed on a computer 
screen that allow control ofthe te^er hardware as a ••vi,««l instrument" The virtual panel 
can be displayed or hidden a. run-time One of fte languages is L^VIEW® which ,s a 
graphical programming language having a collection of virtual ins«umen. (VD files. Anortrer 
,0 language is Laborsaving/CVI«, which uses LabWindows/CVI and CV, in«rch»geably .s 
an ANSI C language-based programming environmen. having a colleCion of C include Ch). 
sou„:e (.0 and library ( lib) files. Bo.h languages ttke advamage of *e VISA ^ NI-DAQ 
in.er&ces and provide an extensive set of test related libraries. 

Although current state-of-the-art test program development architectures take 
25 advantage ofthe current industry and proprietary "best practices," including the template of 
common subroutines and variables provide by the ATP code framework, test program 
development time and maintainability continue to suffer. 

IMM ARY ".^ TNVFNTION 

A test program development method embodied in a data-driven test 
30 architecnrre tha. overcomes limi.ations in the traditional test program developmem process, 
incorporates bes, practices in place in .he indusBy. and (ulfiUs an uWma.e goal of allowng 
.est developmen. personnel .o operate more efficiently. 
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The data-driven test architecture of the invention dramatically increases test 
development personnel's effectiveness by significantly decreasing development time through 
maximizing software reuse, minimizing the amount of programming required for new test 
projects, and providing the test software pro^ammer with a large quantity of tested code and 
3 a basic framework from which to launch a test project. The data-driven test architecture of the 
invention also lowers the programmer's required skill set. which permits non-software 
designers to easily create test programs and make test program changes. The data-dnven test 
architecture of the invention increases test program maintainability by maximizmg 
commonality between test programs, mitigating tester hardware obsolescence, reducmg the 
0 test development designer's involvement in test requirements documentation and 
maintenance, and allows features to be easily added and disseminated to all projects. 

The test program development method of the invention incorporates 
traditional and current test program development practices and state-of-the-art industry 
standards in the data-driven test architecture of the invention as a radical new approach to 
15 creatingtestsoftware.Thetestprogramdevelopmentmethodoftheinventiondramat.cany 
reduces development time for new test projects to the time normally needed just to gather and 

document requirements. Follow-on projects derived from current line-replaceable-umt (LRU) 
test programs can be developed in even shorter periods. Maintenance of these new test 
programs can be shared with LRU product designers to fiarther reduce the burden on test 
20 program development resources. 

The test progran, software development method described herein apphes to all 
new test program development projects regardless of test platform hardware. Re^hosttng of 
legacy programs is applicable on a case-by-case basis. 

Utilizing the best practices, as described herein, provides a solid foundation 
25 and helps define a starting feamre-se, for the novel test program development method of the 
invention. Additionally, any shortcomings in these best practice are identifed and rectified 
in practicing the novel test program development method of the invention. These best 
practices are also extended to achieve the Ml potential of the novel test program 
development method of the invention. 
30 As utilized by the novel test program development method of the invenfon. 

the best practices, as described herein, are effective in reducing test program development 
time and reducing test program maintenance costs and Ume. Accordingly, test program 
development best pra«ices provide commonality in test software components that reduces 
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maintenance time and costs, reusability of software components reduces test program 
development time, and use of component-based architecture enhances reuse, feature sharmg 
and propagation of new test features. Additionally, a common test framework provides a 
common starting place, i.e., template, for all new test projects; enforcement of software 
5 component reuse incorporates component reuse into the test program developmem pro^ss, 
cross-project commonality enhances reduction of maintenance time and costs; basic software 
component interfacing reduces the learning curve for a software designer on a new test 
project utilization of hardware abstraction interfacing, virtual instruments, NI-DAQ analog, 
digital and timer card drivers, and VISA interfaces help mitigate tester hardware 
10 obsolescence. Furthermore, use of common tester hardware across test projects reduces 

hardware abstraction interface coding to a level of write once and reuse. Use of a hardware 
abstraction layer (HAL) permits the test program to run on processor chips developed by 
different manufacturers so that the data-driven test architecture of the invention is able to mn 
on PXI, PCI and VXI test hardware originating from a variety of different manufacturers, 

15 without coding changes. 

The test program development method of the invention as embodied m the 
data-driven test architectv^e described herein thus significantly decreases test program 
development time For example, test program development time is decreased m some 
instances from 1 year or more for currem .est program development projects, to as httle as 8 
20 to 10 weeks. The test program development method of the invention thus so signtficantly 

reduces test program development time that a single test program designer is able to complete 
up to five test program projects in the time it cun-ently u,kes to complete one. Th,s dramafc 
decrease in test program development time is accomplished by maximizing software 
componet* reuse by utilizing the r«.sable novel test executive, test framewori. and software 
25 components of the invention, me amoum of programming required for new projects ts thus 
minimized. As discussed herein, new test program projects only require the creation of one or 
more conttol files so that new test program development requires virtually no new 
programming effort. Rather, the test program development method of the invention as 
embodied in the da,a.driven test architecture described herein provides the test programmer 
30 with a large amount of tested code and a ftamework from which to star, a new test program 
project The invention thus lowers the sHll set required of the test program designer, thereby 
permining non-software engineers to easily create tests and make changes to test p«,grams 
developed using the daU-driven test architecture of the invention. 
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Creation of the control files utilized by the data-driven test architecture of the 
invention does no, require any progran«ning. The test progran, developer only needs 
knowledge of theUUT. This is in contrast to the traditional test program development 
pr^ess vyherein the test program developer must kno» how to interface to the UUT and GSE 
and must know how the UUT operates. The test program development method of the 
inventionasembodiedinthedata-driventestarehitecturedeseribedhereinincreasestes. 

pros-am maintainability because the test programs reside in a eontt^l file, her^n named a ,^ 
properties control file, so that no code maintenance is required. Furthermore, accordmg to the 
test program developmem method of the invention, all test programs use the same test 
executive,tes.frameworkand softwarecomponentssothatcommonalitybetween.es, 

pro-ams is maximized. The .es, program development method of the invention as embod,^ 
in the data-driven test architecture described herein mitigates tester hardware obsolescence by 
incorporating a hardware abstraaion layer that separates the test program ftom the ardware 
interfece. The same tes, program can ,herefore be execu,ed on different hardware platforms, 
such as PCI. PH and VXI. without code changes. 

The tes. program development method of the invention reduces mvolvement 
of ,he test program developer in test requirements documentation and maintenance because^ 
as embodted herein, the test pro-am development method of the invention utrhzatron of test 
database permits LRU product designers .0 create and maintain test program 

The test fi-amework of the invention as described herein is easily updaled for 
use by all projecs so that ,he test program development method of the invention permrts test 
features to be easily added and disseminaied to all tes, projects. 

The test program development method of the invention thus change focus of 
tes, pro-am development personnel from ,he fireflghring mode ,ypical ,oday ,o one of 
processandrestimptovement Some oftite process benefits provided by the tes, program 
developmen, me,hod of ,he invention are a«. documentation becomes part of the tes, 
program development pr»=ess. and software reuse becomes *e core of .he test program 

development process. 

One common problem that is overeome by the test program development 

0 method of ,he presen, inven.ion is ,ha, known stat^of-the-ar. test development methods do 

no, comple,e.y caputre ,est requirements prior «> coding. The test program ^-lopmen 

method of the invention overcomes this problem by .he dau-driven test arehnecture of the 

invention as described herein requiring a compleie ,es, implementation specification .es. 
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description before it will operate. Test program creation is thus moved from the coding phase 

to the requirements phase of the project. 

Another problem with known state-of-the-art test development methods is that 
test parameters must be written to multiple places, the test specification, the test 
implementation specification, and the test program. The data-driven test architecture of the 
invention overcomes this problem by utilization of the test database, whereby all test 
parameters information is entered once and used in multiple places in the test program. 

Additionally, known state-of-the-art test development methods require 
multiple document changes when test limits change. Such changes often occur multiple times 
in the test program when the same limits are used for multiple channels in the test program. 
The test database of the present data-driven test architecture handles all test limit changes so 

that no code changes are required. 

Yet another problem with known state-of-the-art test development methods is 
that code j,roviding tests and fonctionality is often rewritten for each test program project. 
The data-driven test architecture of the invention eliminates such duplication of codmg by 
moving the test program to control files. Additional project-specific "helper" fonctions, as 
described herein, are incorporated into the test framework of the invention as appropriate. 

The test program development method of the invention as embodied m the 
data-driven test architecture described herein also provides support for asynchronous multi- 
station ATP and HASS testing. Multi-station ATP testing permits more manufacturing 
throughput with a single tester, which reduces the number of testers required and thereby 

reduces capital costs. 

Accordingly, the test program development method of the invention is 
embodied in a data-empowered test program architecture having one or more external control 
files that include an external control file having a list of test identification (test ID) numbers; 
a novel test executive module having an execution engine coupled to receive one or more test 
ID numbers from the list of test ID numbers for generating as a fixnction of the test ID a 
plurality of test actions to be performed on a UUT; a test framework that accesses the 
plurality of test actions and associated test equipment hardware resources as a fianction of the 
. test ID number, wherein the test framework determines an identification of one of the test 
equipment hardware resources associated with a current one of the test action, retrieve the 
identification of the associated test equipment hardware resource, determine a signal type 
corresponding to the retrieved test equipment hardware resource identification, access as a 
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function of the signal type one of the external control files having test equipn,ent hardware 
resource card-type information, and determine the test equipment hardware resource 
card-type information as a function of a card-type identifier. 

According to another aspect of the invention, the test equipment hardware 
resource card-type information of the data-empowered test program architecture includes 
routing data and parameters for interfacing with an external hardware driver. 

According to another aspect of the invention, the data-empowered test 
program architecture further includes an external reuse library having a plurality of test 
descriptions corresponding to a plurality of different test signal types. 

According to another aspect of the invention, the data-empowered test 
program architecture further includes a plurality of software components for interfacing 
between the external control files and both the test executive module and the test fi-amework 
module. 

According to another aspect of the mvention, the plurality of software 
componerusprovided in the data-empowered test program architecture of the invention 
further includes one or more modes of pass/fail analysis and test reportmg. 

According to yet other aspects of the invention, the test program development 
method of the invention is embodied as a computer program product provided on a computer 
usable medium having computer-readable code embodied therein for configuring a computer, 
the computer program product providing computer-readable code configured to cause a 
computer to generate a plurality of test actions; computer-readable code configured to cause 
the computer to access the plurality of the tes, actions, computer-readable code configured to 
cause the computer to identify a tes. equipment hardware resource associated wnh a current 
one of the test action; and computer-readable code configured to cause the computer to 
imerface with an external hardware driver as a fiinction of the test hardware resource 

associated with the current test action 

According to another aspect of the computer product embodiment of the 
invention, the computer-readable code that is configured to cause the computer to interfece 
with an external hardware driver fi«her includes computer-readable code configured to cause 
30 acomputerto: determine a signal type corresponding to the identified test hardware resource; 
access as a fimction of the signal type an external control file having test hardware resource 
card-type information contained therein; and determine the test hardware resource card-type 
information as a function of a card-type identifier. 



20 
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According to another aspect of the computer product embodiment of the 
invention, the computer-readable code that is configured to cause the computer to generate a 
plurality of test actions further includes computer-readable code configured to cause the 
computer to receive from a list of test ID numbers one or more test ID numbers, and to 
5 generate the plurality of test actions as a function of the received test ID number. 

According to another aspect of the computer product embodiment of the 
invention, the computer product forther includes computer-readable code configured to cause 
the computer to perform a pass/fail analysis and to generate one or more test reports. 

According to another aspect of the computer product embodiment of the 
10 invention, the computer product further includes computer-readable code stored in one or 
„.ore software components and configured to cause the computer to interface between the 
computer-readable code configured to cause the computer to generate a plurality of test 
actions and the computer-readable code configured to cause a computer to access the 
plurality of the test actions. 
j3 RttTFF DESCRIPTTON OF THE DRAWINGS 

The foregoing aspects and many of the attendant advantages of this invention 
will become more readily appreciated as the same becomes better understood by reference to 
the following detailed description, when taken in conjunction with the accompanymg 
drawings, wherein: 

20 Figure 1 is a block diagram that illustrates a traditional system test 

architecture; vu*u^ 
Figure 2 illustrates that, in any given test, the test typically i«erfeces with the 

unit-under-tes. and a.e gmund support equipment multiple times to obtain response readmgs 

based on specific stimuli; 
25 Figure 3 is a block diagram of a current state-of-the-art test architecture; 

Figure 4 and Figure 5 are top-level and high-level block diagrams, 
respectively, that together illustrate one embodiment of the data-empowered test architecture 
of the invention for test program development; 

Figure 6 illustrates the project-specific control/support file interfacing of the 
30 data-empowered test architecture of the invention embodied in a mid-level architecture 
diagram; 

Figure 7 illustrates a sample test description of the invention; 
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Figure 8 illustrates the common test procedure source for both the test 
implementation specification and the test properties control file, wherein the test procedure 
data are optionally exported from the database to both the test implementation specification 
and the test properties file of the data-empowered test architecture of the invention, m the.r 

5 respective formats; 

Figure 9 is an exemplary illustration of one embodiment of a test procedure 

portion of the test implementation specification test description illustrated in Figure 7 
wherein the example illustrated is an analyze mode test procedure of the mventton; 

Figure 10 compares traditional signal-specific tests of the prior art systems to 
10 the generic data-driven test provided by the data-empowered test architecture of the 
invention; 

Figure 1 1 illustrates test execution using the test procedure interpreter of the 

invention; . , 

Figure 12 illustrates the test framework of the invention embodied m a block 

1 5 diagram wherein a SET action is illustrated; 

Figure 13 illustrates the interface of the test framework of the invention to the 
hardware abstraction interface of the invention as embodied in ablock diagram; 

Figure 14 illustrates the operation of the hardware abstraction interface of the 
invention with commercial off-the-shelf vendor drivers embodied in a block diagram; 
20 Figure 1 5 is a block diagram that embodies an exemplary summary of the 

steps of the test procedure of the invention for interfacing with low-level vendor-supplied 

hardware drivers; and 

Figure 16 illustrates an exemplary "helper" fimction of the invention. 

PPTATT pn nFSrRTPTION O F PREFERRED FMBODIMENT 

25 In the Figures, like numerals indicate like elements. 

The test architecture of the invention is embodied in a data-empowered test 
architecture that overcomes the shortcomings in the traditional test program development 
process, incorporatesbest practices in place in the industry.and fulfills the ultimate g^ 

allowing test development engineers to operate more efficiently. 
30 Figure 4 and Figure 5 are top-level and high-level block diagrams, 

respectively, that together illustrate the test program development method of the invention 
embodied in a data-empowered test program architecture 100 that utilizes a test framework 
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„KKlule 102. a «»utive module 104, a plurality of software components in a software 
components module 106. and one or more external control files ,08 hardware abstraCon 
included in the architecture enables the code-base of the data-empowered test arch.tecture of 
the invention to work with virtually all current tester hardware, including by example and 
without limitation all of PXI, PCI. VXI. 

The eode-base of the data-empowered test architecture 100 of the invenfon 
illustrated in the top-level block diagram of Fi».re 4 is generic and configured by external 
control files 108 to test the unit-under-test (UUT) and generate one or more test repom 1 10. 
Because it is data-driven, the data-empowered test architecture 100 of the invention provrdes 
, the developer of a new test project with virtually all code required for a test project. The 
data-empowered test architecture 1 00 of the invention thereby reduces new test project 
developmem is thereby reduced to creating one or more control files 108 to configure the 
data-empowered test an*i,ecture. An external reuse library 1 12 is a usefirl reference for 
program developers in creating the contml files 108 and includes test descriptions of common 
5 signal types used across a using manufacturer's products. This is a "best practtces" test 
methodology that captures lessons learned from experience. 

The code-base of the data-empowered test architecture of the invention that is 
fi^mished to each p^ject is debugged and tested. For example, the test framework 102, test 
executive 104 and software components 106 of the data-empowered test architecurre 100 are 
,0 developed under well-known capability maturity model level 2 processes which are much 
more comprehensive than the DO-178B Level E processes normally assoctated wth test 
program developmem. The debugged and tested code-base of the data-empowered test 
architecture is contained in the test framework module 102, the test executive module 104, 
the software components module 106, and a ground support equipment (GSE) mterface 
25 module 114 fo, driving the ground support equipment. These modules and the external reuse 
library 1 12 are opfionaUy standalone executables. Dynamic Link Libranes (DLL), test 
descriptions 1 57 (shown in Figure 7), or code that is ready to be Unked into the new test 

^'"'^ The data-empowered test architecture software: test framework module 102, 
30 test executive module 104. and all software components of the software components module 
106 are provided as separate CSCIs (computer software configuration items). Each test 
program is also a separate CSCI that may include the system software as part of a test 
program setup package stored on a computer disk or other computer-readable medmm. By 
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including all software as a single setup package, i.e., computer disk, except vendor-supplied 
hardware drivers, the correct version of each component is captured as part of the test 

program. , ^ . 

Tea pmgrams include the following common CSCIs: the data-empowered test 

architecture test ftamework 102. test executive module 104 and software components module 
,06 that includes a pass/«l analyzer and repon generator (PFARO). atest properties reader 
(TPR) 136 a hardware properties reader (HPR) 132. a common test dialog (CTD) 142. and a 
UUT configuration matrix access and verification (CMAV) reader 138. When the test 
platform hardware is configured, a hardware properties control file (HPF) 134 is created by 
the platform hardware designer This file is released as par, of the hardware configura«on 
control package. The hardw^e properties control file 152 is installed on the test platform «,d 
the name and path of the hardware properties control file 1 52 are entered into the operatmg 
system re^stry so the data-empowered test architecture software of the invention is able to 
locate it. 

According to one embodiment of the invention usefi.1 for aircraft cockp.t 
Hne-replaceable unit (LRU) products, each test program additionally includes an ARINC 625 
test specification (TS) 158, an ARINC 625 test implementation specification (TIS) 156. a test 
propenies control file 1 52, a UUT conflgumtion matrix file 140. a software module 
checksum file 150, formal test sequence control files 154, and any project specfic code. 

Operation of the data-empowered test architecture 100 of the invemion .s most 
clearly illustrated in Figure 1 1 Accordingly, as discussed in detail below, the one or more 
extermd coMrol files 108 created by the test development engineers provides a hst of test 
identification (test ID) numbers 159 that are contained in a test sequence control file 154. The 
tea ID numbers 159 are used by an execution engine 1 16 portion of the test executive module 
,04 to provide a sequence of test operations or "actions" 1 1 5 to be performed on the UUT 
The execution engine 1 ,6 steps through the test ID numbers ,59, passing the test m numbers 
,59 one a. atime to atest p«>cedure interpreter ,24 portion of the test fl^tework module 
102 The test procedure imerpreter 1 24 uses the test ID number 1 59 to access a plurality of 
the test actions 1 15 and associated test equipment hardware resources 176 stored in a 
spreadsheet-formatted test properties comrol file 152. The test procedure interpreter 124 
determines the name of a test equipment hardware resource 176 associated witi, the current 
test operation or action 1 1 5. The test procedure interpreter 124 retrieves the name of the 
associated tester hardware resource ,76, and passes the tester hardware r^urce 176 name to 
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an action dispatch and routing module 173 portion of the test framework module 102. As 
illustrated in Figures 12 and 13 and discussed in detail below, a portion of the action despatch 
and routing module 173 determines a signal type 178 corresponding to the retrieved hardware 
resource 176 name, whereupon control is passed to the hardware abstract interface (HAI) 
5 128 AsiIlustratedinFiguresl4andl5anddiscussedindetailbelow,thehardwareabstract 

interface 128 uses the signal type 178 to access the hardware properties control file 134 and 
determine the hardware resource card-type 1 84 as a function of a card-type identifier 185, 
such as -NI-324r illustrated in Figures 13 and 14. The hardware abstract interface 128 is 
thereby enabled for routing data and parameters to and from vendor-supplied hardware 
10 drivers, i.e., interfacing with the vendor-supplied hardware drivers. 

The data-empowered test archhecture 100 of the invention uses a novel test 
executive 104 that includes a novel muki/single-unit execution engine 1 16, a novel 
proprietary user interfece 118, and novel pass/fail analysis and reporting processes 120 
provided by the software components module 106. The muhi/single-unit execution engine 
15 116 includes built-in hardware resource management capability, support for user-defined 
sequences, and execution control that provides such control features as. stop^n-fml, 
sequence loopmg, skip test, skip test group, pause and abort fonctions. The user interface 1 1 8 
provides a GSE status view, and a UUT view that includes a test report view, a test status 
view and an instalment I/O trace view. The pass/fail analysis and reporting process 120 is 
20 optionally a commercial product provided as part of the software components module 106, 
and includes built-in support for statistical process control (SPC) reporting, for example m a 
conventional spreadsheet format such as an XML (extensible markup language) format. 
However, limitations related to these fonctions in commercial test executives caused this 
fianctionality to be broken-out into a component. Additional logging modes are included 

25 along with additional testing types. 

The novel test executive 104 of the invention includes several features that are 
not available in a commercial off-the-shelf executive. Modification of a commercial 
off-the-shelf executive to incorporate these features may be possible, but such modification is 
not cost effective due to the additional developer training required and the additional time and 
30 resources needed to create and maintain the modified executive. 

In smaller development teams allowing developers to create software m 
whatever language with which they are most comfortable may be problematic. For example. 
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if programmer .eav« the team or becomes u^vailable, ,he code becomes „o„-m««Uinable 
unless another programmer on the team is familiar with the language. 

An ability to run modules built from multiple languages, as is provided by one 
or more commercial off-the-shelf executives, is no. needed when a development languages 
5 selected that allows the test executive 104 to run Dynamic Link Libraries (DLLs) buih from 
any language, as discussed he,*in. The multi-language support feature p^ m some 
commercially available executives does not provide any advantage in the environment of the 
data-empowered test architecture of the invention at least because so little programmtng ts 
performed when creating a new test program. For maintenance purposes, it is important no, to 
10 abuse multi-language support provided by any test executive 

The novel test executive 104 utilized by the data-empowered test architeewre 
of the invention provides dynamic test sequencing that is controlled by the extental contn,! 
files 108 The novel test executive .04 also provides a user interface that supports Cher an 
Acceptance Test Procedure (ATP) or a Highly Accelerated Stress Screening (HASS) 
15 environment and additional pass/fail analysis modes beyond those normally provided by 

commercial test executives. The novel test excnitive 104 permits formatting of the test report 
1 ,0 Furthermore, the novel test executive 104 provides the report data to be output m SPC 
forma, to support SPC programs. The novel test executive 104 supports multi-station testing 
by providing built-in tester hardware resource management, b« utilization of the test 
20 executive 104 of the invention avoids the run-time license fees associated with comme„=ial 
test executives. 

A major problem in the prior art is a lack of consistency in common 
signal-type tests across pn>jects. According to .he set of tcs. descriptions provided by .he 
external reuse library 112, all projects test the same signal-types in the same way according ,o 
25 a set of test requirements defined for each signal-type and a set of test descriptions that have a 
high degree of completeness and rigor. 

The reuse Ubrary test descriptions are optionally shared across a using 
manuf^er-s product lines to provide a common tes. mettiodology .o all internal test 
programs, whether or not the data-empowered test archi.eemre of tiie invention is utilized^ 
30 The following is a sample test description 157 of tiie test implementation specification 156 
for ARINC 429 receiver testing. 
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In an aircraft environment, outputs of avionics on the aircraft are present as 
data signals on the aircraft ARINC-429 serial bus and consist of 32-bit packets. The packets 
are defined in Table 3. 



Table 3 



) 



BIT 


DESCRIPTION 


0 ... 7 (8 bits) 


Signal Label. An octal word that identifies the avionics sending 
the data and therefore the signal type. 


8 ... 30 (23 bits) 


Data. The format of the data and its meaning varies dependmg 
upon the type of signal. 


31 (1 bit) 


Parity. AT indicates odd parity. 



In the special case ui mi ai^^iaxt ^.^-v. 

accessing the aircraft ARINC-429 serial bus and monitoring the outputs of other avionics on 
the aircraft to obtain information on cuirent flight parameters. The aircraft may have several 
ARINC-429 buses that operate at one of two speeds: High (lOOKHz) or Low (12.5KHz). The 
LRU product is capable of accessing and "listening" to these buses to obtain relevant data 
such as altitude, air speed, flap position, and other relevant data. The ARINC 429 transceiver 
chips are optionally programmed to only accept certain Labels, which allows the LRU 
product to do selective "listening" such that data packets from non-selected aviomcs are 

ignored. , 
ARINC-429 input tests are performed to verify that the LRU product s 

hardware is capable of correctly receiving data at both High and Low speeds. Testing is 

provided by transmitting data packets from the GSE to each of the LRU product's receiver 

channels and verifying, via the appropriate UUT interface, that the correct data was received, 

that the data was received on the correct channel, and that the timestamp for the data is 

present. The data packets chosen for testing are selected to provide short/open checking on 

the ARINC 429 data bus. By example and without limitation the data packets on the ARINC 

429 data bus for testing include. Signal l^el, which is an octal word that identifies the 

avionics sending the data and therefore identifies the signal type; Data, having a formats and 

meanings that vary depending upon the type of signal; and Parity. Testing is also designed to 

perform the more thorough testing at high speed in order to minimize test time. 
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The Low Speed Input Testing of the LRU product's receiver channels includes 
data verification and low amplitude threshold testing. These tests are combined to minimize 
test time Typically, no attempt is made to verify the Label Recognition or Parity funct.ons of 
the ARINC-429 Receivers, since these are either tested as part of the BITE or as a separate 

5 test. . ^ , 

The High Speed Input Testing of the LRU product's receiver chamiels 

includes data checking, and time stamp verification. A normal signal amplitude is used 
during this test. No attempt is made to verify the Label Recognition or Parity functions of the 
ARINC-429 Receivers, since this is tested as part of the BITE or as a separate test. 
10 The reuse library 1 12 is in two parts, the test specification (TS) 158 and test 

implementation specification's test descriptions 1 57 for all common signal testing, wherem a 
Phase 1 is a text document template in a word processing format such as a conventional 
document template, and wherein a Phase 2 is a user test database; and a spreadsheet control 
file template for insertion into a project test properties file, shown in Figure 8. 
15 According to the invention, the reuse library 1 12 is dynamic and is updated as 

test projects add new signals or advance the signal testing methodology. Changes made for 
one project are thereby available for all other projects to use. LRU product engineering 
personnel also use the test descriptions of the reuse library 1 12 when specifying test 
requirements. 

20 The test framework embodied in the test fi^amework module 102 provides the 

following fimctional blocks, a component interface 122; a test procedure interpreter (TPI) 
124; action dispatchers (AD) 126; and the hardware abstract interface (HAI) layer 128 having 
both abstraction routers 180 and abstraction handlers 182, shown in Figure 13. 

The component interface 122 represents incorporation of test program 
25 development best practices as known in the prior art and discussed above, and provides the 
fixnctionality described in regard to the ATP code framework as known in the pnor art and 
discussed above. Briefly, it provides interfacing to and setup of the software components 106 
and also provides a common set of subroutines that are used to perform UUT and GSE 
inirialization. These subroutines reference procedures, such as Gselnit (GSE initiation), 
30 Uutlnii (UUT initiation) and UutPo^er (UUT power), which are present in the test properties 

file, shovm in Figure 8. 

In order to make the data-empowered test architecture 100 of the invention 
effectively data-empowered or "data-driven," the system software contains generic code that 
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is configu^ble by external oonm.1 He. .OS ,o perform specific UUT .es,s Th,s ab, .y .o be 
configun.b.e by external comrol files is performed by .he test procedure interpreter .24 
portion of the test framework 102 which processes the test procedure vocabulary of the test 

implementation specification. 

Hardware abstraction, as known in the prior art, is extended to the test 
program by incorporation in the h^dware abstract interfece .28 which separates the test 
program from the hardware interface and permits the data-empowered test architecture .00 of 
the invention to run on conventiona. PH. PCI and VXI test hardware from a «u.ety of 
manufteturers, without coding changes^ The hardware abstract interface .28 thereby 
mWgates tester hardware obsolescence and to permits the test framework module .02 to 
accommodate aU test projects As discussed herein, the hardware abstract interftce 128 
interfeces wiU, vendor-supplied hardware drivers 130, which drive the test platform 13. 

having the GSE for interfecing with the UUT. 

Figure 6 is a mid-leve. a.x=hitecture diagram of the data-empowered test 
architecmre 100 of the invention that illustrates test project-specific control/support file 
interfacing. As described in the prior art and discussed herein, the use of software 
components has been known to increase softw«e reuse and commonality. The software 
components known in the prior art and described herein are included in tite data^powered 
test architecture 100 of the invention. In addition, components tita. perfonn interfi^mg to the 
extendi contiol files 108 are added to the suite of software components contatned m the 
softw^e components module 106. The software components module 106 thus inCud^ the 
following software components: the hardware properties reader (HPR) 132 that provides 
interftcing to the hardware properties file (HPF) .34 which is one of control fi.es .08; the 
test prt>perties reader (TPR) .36 that provides interfacing to a test properties fi.es .52 whrch 
i is another one of control files 108; the UUT configuration matrix access and venficat.on 
(CMAV) reader 138 that provides access to a UUT configuration matrix file 140 wh.ch >s 
another one of contrt,. files 108; the common test dialog (CTD) 142; and a pass/fai, analyzer 
and report generator (PFARG) .44 titat provides several modes of pass/fai. analysrs as weH 
as providing test reporting. The pass/M. analyzer and report genemtor 144 supports SPC data 
0 collection which is used to track UUT performance and to improve product ytelds. 

Optionally, the test data is output to a Results Database 146 for use in improving test ngor 
and comprehensiveness. For example, the pass/fai. analyzer and report genera«>r .44 outputs 
■ bofl. test reports 1.0 and statistical process control (SPC) data 148 in forma, stntctured to 



Patent Application 

Attorney Docket No.: H0003463 



25 



support SPC programs. The common .est dialog 142 provides data gathering for the test 
program, including for example the operator name, the UUT serial number, the UUT part 
number and the test report modes. Furthermore. ,1« common test dialog 142 provides data 
display for the test program, and is configurable to suit the test project 

The d.ta-empo«.ered test architecture 100 of the imrention is data-dnven by 
use of the external control files 108 which are opfionally configured as one or a plurality of 
external contral files 108 and include: the UUT configuration matrix control file .40 whrch 
contains data relating to all hardvvare resources 176 present in the test platform 131; a check 
sum control file 150; one hardware properties control file 134 per tester; onetestpropefes 
> cont«>l file (TPF) 1 52 per test pro-am set (TPS), which contains all test data; test sequence 
control files 154 having an Acceptance Test sequence, a retum-to-service sequence, and other 
user-defined sequences. Tester hardware configuration control is enforced by couphng 
fl^ough the hardware properties file 134 ofthe data-empowered test architecture 100. 

Unknown or unsupported configurations simply do not work. All interfacing to the UUT ,s 
5 accomplished by making calls to the GSE interftce 1 14. Performing UUT control is therefore 

operated via the test properties file 152. 

The GSE interface 1 14 is structured such that as new hardware is added to the 
user's test platforms, the responsible hardware engineer or system software engineer provides 
interftce functions to the vendor-supplied hardware drivers 130 and updates the ftamework 
20 hardware abstract interface 128tousethenewfl.nctions. See. for example, the block dtagram 
illustrated in Figure 13 and discussed herein The OSE imerface 1 14 is expected to grow as 
new hardware is needed for test projects. Once added to the test ftamework of the invemton. 
the new hardware becomes accessible by all test projects. Use of these ft.nc.ions is specrfled 
in the test properties file .52, along with relevant parameters. ARINC 429. ComPort and 
25 ^nufag example interftce Sanctions are as follows; 

ARINC429Init COMPORT Open NlDAQInit 

ARINC429 0ut COMPORT Out NlDAQOut 

AWNC429In COMPORT In NIDAQln 

COMPORT Close 

The following provides a more detailed description of the data-empowered test 
architecture 100 of the invention including: coupling of the ARINC 625 test implementation 
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specification; defining tests in a data-driven architecture; generic tests; the test framework 
component 102; and the hardware abstract interface component 128. 

Figure 7 illustrates a sample test description 1 57 of the test implementation 
specification 156 for a Flight DataRecorder Analyzer Mode Test of the Assignee. As 
5 discussed above, the test implementation specification 1 56 is one of two separate 

specifications defined by ARINC 625-1 and describes how the test specification (TS) 158 is 
implemented on specific GSE and provides shop verification of the test specification 158. 
The ARINC 625-1 test implementation specification 156 is one of the two parts of the reuse 
library 1 12 and provides a detailed description from a tester perspective of all tests performed 
10 during Acceptance Test, along with the tester resources 176 utilized by each test. As 

illustrated in Figure 7, one sample implementation of test descriptions 157 withm the test 
implementation specification 156 provides the unique test Identification (test ID) number 159 
that is traceable to the test specification 158 and referenced in the test report 1 10. The test ID 
number 159 is also used by the test properties and Sequence control files 152, 154 (shown m 
15 Figure 6). The sample implementation of test description 157 illustrated in Figure 7 provides 
UUT signal data 160 and subassembly (SRU level) data 162, a textual descriprion 164 of the 
test and a test procedure 166 for the test that may be in the form of the vocabulaiy-based 
pseudo-code of the test implementation specification 156. A listing of the vocabulary of test 
implementation specification's vocabulary-based pseudo-code is shown by example and 
20 without Umitation in Table 4, as formatted according to: COMMAND <required data> 

[optional data] [optional text]. These vocabulary words are used to formalize the syntax for 
use in describing test procedures. When the vocabulary words appear as shown m Table 4, 

they convey the given definitions. 

j^^^^,^^^^,,^,,!,^,. APmr 69.5-1 Te st Implementation Specification 156 



COMMAND 



DESCRIPTION 




CLOSE <equip_name>: 



<COMMAND> END 



Close a device such as a ComPort. This is the 
opposite of the OPEN mnemonic. 



Command a continuous operation such as IN or 
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<equip_name>: | ^ 


)U 1 to eno. 


COMPARE, VERIFY. ^ 


»ass/Fail test of measured value to defined limits. 


CONTAIN(S): ^ 

1 


K string parameter 'contains' a substring. 
Example: "Abcdefg" CONTAINS "code". 


DEFINE: ^ 


Defining a procedure that is associated with a 
mnemonic. The procedure definition may include 
parameters that will be assigned or given values 
for a given context (parameter substitution). 


DISCARD: 


Disregard data read in from the UUT, RS-232 or 
other device. In some cases extra data is returned 
that is not needed by the test but that must be read 
:^ ^^Aor in find the correct data in the data stream. 


ELSE: ^ 


Alternate conQuionai uiaiivn. 


EXIT: 


Exit LOOP or subroutine. 


TF expression, action: 


1 Conditional branching at a procedural level, 
"ejcpress/o«" resolves to a Boolean True/False 
and "action" may be a key word. E.g. IF Mod 
level EQ A, PERFORM .... 


IN <equip_name> [countOperiod]: 


1 Input data, using protocol appropriate for the 
signal type or instrumem, either "co««f' times or 
for "period". If "count" and "period" are not 
defined, then input continues until an END 
command is performed. 


jNTT <eguip_nanie>: 


Send initialization parameters to an instrument or 

device. 


1 LOOP [UNTIL]: 


Repeat the procedure UNTIL a condition is met. 


NOTIFY [message]: 


Mntifvtheuser of a condition or event. Provide 
the user with instructions. 
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OPEN <eguipjicane>: ^ 

£ 

1 

1 


)pen a device such as a ComPort. This is a 
.pecial case of the INITIALIZE command since it 
las a corresponding CLOSE command. This is 
the opposite of the CLOSE mnemonic. 


OUT <equip_name> [countOperiod]: 


Output data, using protocol appropriate for the 
signal type or instrument. Either "count" times or 
for "period". If "count" and "period" are not 
defined, then output continues until an END 
command is performed. 


REPEAT / [countO FOR EACH] 


Execute associated procedure either "coi/nr" times 
or once FOR EACH element in a specified list or 
table. is the zero-based iteration count 
variable that can be referenced inside the 
procedure. 1 


REPORT. 


Write the specified message to the test log. 


RESET <equip_name>: 


Reset a condition, using the named equipment, as 
defined in text. This command typically resets a 
previously SET condition. For digital signals, 
RESET places the digital output in its Inactive 
state. 1 


SCALE <readmg> . conversion: 


Perform provided scaling on the specified 
reading. 1 


SET <equipjiame>. 


Set a condition, using the named equipment, as 
defined in text. For digital signals, SET places the 

A\f^\*^r%\ /Mifniit in it<i Active St&tC I 
Qlgltm OUipUl 111 11^ r^viivKy .jww. 


UNTIL. 


Defines a condition that will end a LOOP. 


WAIT: 


rioiow firww of teit for defined time. May use min 
or error limits. 
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The test implementation specification's test procedure 166 and its 
pseudo-code are tightly integrated into the data-empowered test architecture 100 of the 
invention in the form of the test procedure interpreter 124 for processing the test procedure 
166 vocabulary. By directly reading this pseudo-code, the data-empowered test architecture 

5 of the invention drastically reduces test program development time by eliminating the 

time-consuming coding phase from the test development process. By using the control files 
108, along with the test procedure interpreter 124 and hardware abstraction, the test 
implementation specification's test procedure 166 becomes the test program code. 

As illustrated in Figure 7, all test data present in the test implementation 

0 specification's test description 157 optionally resides in one location through the use of a 

proprietary or other database. 

Figure 8 illustrates the common test procedure source for both the test 
implementation specification 156 and test properties file 152 wherein the test procedure 166 
data are optionally exported from the database to both the test implementation specification 
15 156 and the test properties control file 152, in their respective formats. As illustrated by the 
example, the test requirements are entered by a requirements editor 168 into a proprietary or 
other database 170. The test procedure 166 portion of the test implementation specification 
1 56 is operated and is output in the format of the test implementation specification 156 and m 
the format appropriate for the test properties file 152, illustrated by example and without 

20 limitation as a CSV/XML format. 

This approach also solves several problems that have historically plagued 
pseudo-code of the prior art. For example, in the prior art the pseudo-code and the actual code 
often diverge as changes are made to output the test procedure in one format and not the 
other in the prior art the pseudo-code cam^ot be executed to ensure its accuracy; and m the 

25 prior art the pseudo-code implementation, i.e., the vocabulary, varies between different test 
projects. 

The data-empowered test architecture 100 of the invention utilizes a database 
report to create both the test properties control file 152 and the test implementation 
specification's test description 157 so that synchronization problems, which are inherent m 
30 the prior art, are eliminated in the present invention. In contrast to the prior art, accuracy is 
ensured in the present invention because the files are actually tested as part of test program 
verification. Unlike the prior art, the data-empowered test architecture 100 of the invention 
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utilizes a database with common data fields and ARINC 625-1 document templates wrth a 
predefined vocabulary that ensures consistency across different test projects. 

Figure 9 is an exemplary illustration of one embodiment of the test procedure 
portion 166 of the test implementation specification's test description 157 illustrated in 
5 Figure 7 wherein the example illustrated is an analyze mode test procedure of the mvention. 
The test procedure 166 illustrated in Figure 9 identifies components of a test: tester resources 
176 test data; and actions 115: Close, Mt, Perform, Start, End, Open. Reset, Stop, In, Out, 
and5er. WAlT^n6. ^^iJ/FK are verbs defined in the vocabulary ofthe test implementation 

specification 156 but are not "actions" 1 15 as defined herein. 
10 Creating tests is the sole activity of traditional test program development of 

the prior art Figure 10 illustrates that in traditional prior art systems, indicated generally at 1, 
each test tends to be a custom test with parameters, test equipment hardware resources and 
tolerances embedded in the test code. Making simple changes in the traditional pnor art 
systems can and often does require touching large numbers of tests, which is time consummg 
15 and error-prone for both new development and maintenance. 

Figure 10 compares traditional signal-specific tests of the prior art systems 1 
to the generic data-driven test provided by the data-empowered test architecture 100 of the 
invention Figure 10 illustrates that, by contrast to traditional prior art systems, any test is just 
another form of externally configurable code in the data-empowered test architecture 100 of 
20 the invention. Because the data-driven test of the invention is configured according to the test 
properties control file 1 52, the data-driven test 172 of the invention is a genenc test. 
Utilization of data-driven tests that are stmctured as externally configurable code allows tests 
in the data-empowered test architecture 100 of the invention to move away fi-om signal-based 
tests, such as a specific ARINC 429 receiver or an analog output test, as practice m the pnor 

25 art. .,. . 

The data-empowered test architecture 100 of the invention is able to utilize the 

generic test interpreter implemented by the test procedure interpreter 124 of the invention 
because testing according to the data-empowered test architecture 100 is based on a set of 
actions 115 that describe the generic test in a signal-independent mamier. The genenc 
30 data-driven test 172 of the invention is capable of perfonning tests that in prior art systems 
required custom coding. All tests defined in the sample test properties control file 152 shown 
in Table 5 can be executed as a generic data-driven test 172 according to the data-empowered 
test architecture 100 of the invention. 
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Table 5 Samp''^ T^st Prooert i^«: (test param eters not shown ) 



iTestlD 



"estName 



TestGroup 



11001 



RS-232 RX 



RS-232 



U002 



RS-232 TX 



Action iResourceName 



Open ICOMI 



O pen RS232 MONITOR 



Set 



Out 



Close 



RS-232 



l Open ICOMI 



Open RS232 MONITOR 



Set IRELAY 232 422 



ait RS232 MONITOR 



no5i 



RS-422 RX 



RS-422 



[1052 



RS-422 TX 



lllOl 



ARESrC 429 RX- 



1102 



U8051 



RS-422 



RELAY 232 422 



TCOMl 



RS232 MONITOR 
ICOMI 



In 



ICOMl 



Close [COMl 



Open ICOMI 



Open 



Reset 



| RS232 MONITOR 
RELAY 232 422 



Out ICOMI 



}^ |rS232 MONITOR 



Close I COMl 



Open ICOMI 



Open RS232 MONITOR 



Reiit iRELAY 232 422 



Out RS232 MONITOR 
lii ICOML 



Close ICOMI 



ARINC429 



n..t |aRINC429 TX20 
IRS232 MONITOR 



ARINC 429 TX 



ARINC429 



FDR Analyze 



liiit 1ARINC429 RX20 



FDR 



tin 1aRINC429 TX20 



^nit |ARINC429_1 



Mt lARINC429_T 



alt RS232 MONITOR 



In 



Perform 



Set 



Out 



In 



ARINC429 RX20 



Data 



1485 



1485 



54321 



54321 



232323 



iDISCOUT ATE PRESENT 



ARINC717 TXl 



DISCIN MAINTENANCE" 



lii IdISCIN STATUS 



232323 



5555 
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2001 



Power Supply, 
Voltage 



Power Supply 



In 



End 



Reset 



BITE LED 
ARINC717 TXl 



DISCOUT ATE PRESENT 



Init 



Set 



Set 



In 



Reset 



Reset 



PS ACl 



RELAY PSfflGH 



RELAY PSLOW 
DMM 



RELAY PSfflGH 



RELAY PSLOW 



Examination of the FDR Analyze mode (test ID 18051) sample in Table 5 
shows a set of actions 115 to be performed using the specified test equipment hardware 
resources 176 and data, the actions 1 15 to be performed being: Perform, Set, Out, In, End, 
and Reset. 

5 Figure 1 1 illustrates test execution using the test procedure interpreter 1 24 of 

the invention. As illustrated in Figure 1 1, the test procedure interpreter 124 reads all actions 
115 defined for a given test ID 159 from the test properties file 152, and then executes these 
actions 1 15 in the order they are listed. The test procedure interpreter 124 steps through each 
action 115 for the given test ID 159 in the test properties control file 152. and for each action 
10 115 launches in serial format action dispatch/routing code that is embodied in the action 
dispatch/routing module 173. The Perform, Set, Out, In, In, In, End, and Reset actions 115 
are thus performed as indicated generally at 174 before the dispatch/routing code launches 
the action 1 15 to the framework hardware abstract interface module 128. 

The test framework software code embodied in the test framework module 
15 102 of the invention provides the interface between the execution engine 1 16 and the 

hardware abstract interface 128. The test framework module 102 includes the test procedure 
interpreter 124; the action dispatchers 126 and routers 180, shown in Figure 13 and discussed 
in detail below, both embodied in code in the dispatch/routing module 173; and the hardware 
abstract interface module 128. The test framework module 102 processes the actions 115 
20 present in the test properties file 152, wherein only one action dispatcher 126 is provided per 
vocabulary action 115 of the ARINC 625 test implementation specification 156. 

Figure 12 illustrates the operation of the test framework 102 embodied in a 
block diagram wherein the SET action 1 1 5a is illustrated. The test procedure interpreter 124 
steps through the test properties control file 152 using the test ID 159 as supplied by the 
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execution engine 1 16, and launches the test procedure interpreter 124 for each of the actions 
115 found. As the test procedure interpreter 124 determines what action 115 to perform, 
control is passed to the appropriate action dispatcher 126 for forther processing. Figure 12 
illustrates the operation of the test framework 102 and test procedure interpreter 124 
processing for the Set action 115a, wherein the Set action dispatcher is indicated at 126a. 

Figure 13 illustrates the interface of the test framework 102 of the invention 
with the hardware abstract interface 128 of the invention as embodied in a block diagram. 

An action dispatcher 126 is provided in the data-empowered test architecture 
100 of the invention for each action 115 provided in the test implementation specification 
156 including. Set AD (action dispatcher) 126a, Reset AD 126b, Perform AD 126c, Open 
AD 126d Out AD 126e, Mt AD 126f, In AD 126g, and Close AD 126h, as shown in Figure 
12 Each action dispatcher 126a-h possesses a set of tester signal-types 178 that it is capable 
of accessing. For example, the Set action dispatcher 126a may only support a Discrete Output 
tester signal type 178a, while the Out action dispatcher 126e may support ARINC 429, 
ARINC 717 RS-232, RS-422 and AnalogOut tester signal types, or other signal types. The 
action dispatcher 126 determines what signal-type 178 is being accessed by the test procedure 
step of an operation by reading test equipment hardware resource data 176 from the hardware 
properties control file 134. The action dispatcher 126 thus uses the hardware resource data 
176 as an index into the hardware properties control file 134 and obtains the signal type 178 
from the hardware properties control file 134. The action dispatcher 126 then passes control 
to an appropriate abstraction router 180 in the hardware abstract interface 128. 

Figure 14 illustrates the operation of the hardware abstract interface 128 of the 
invention with commercial off-the-shelf vendor drivers 130 as embodied in a block diagram. 
The hardware abstract interface 128 provides one abstraction router 1 80 per tester signal-type 
178. The hardware abstract interface module 128 also provides one abstraction handler (AH) 

182 per signal-type hardware driver. 

The data-empowered test architecture 100 of the invention minimizes the 
effect of hardware changes on the test program by taking advantage of industry initiatives 
such as IVI VISA and M-DAQ. These well-known and common interfeces provide access to 
) a family of cards, thereby allowing different cards to be installed without affecting the test 
program. The hardware abstract interface 128 is updated to enable the test program to access 
new hardware that is not supported by these initiatives. Once updated, all projects then 
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accommodate the new hardware by upgrading to the revised version of the data-empowered 

test architecture 100. 

The abstraction routers 180 accesses the hardware properties control file 134 
to determine the hardware resource card-type indicated at 184. The abstraction routers 180 
then direct the test procedure aaion data and parameters to the appropriate abstraction 
handler 182. The tester hardware properties control file 134 is queried to determine the 
card-type 184, as illustrated in Figure 14. The card-type 184 is determined as a function of a 
card-type identifier 185, such as 'W/-32^3" shown. For vendors that supply common drivers 
to all cards they manufacture, this card-type identifier 185 may just be the manufacturer's 
name. For other vendors, the card-type identifier 185 specifies more detailed identification 
information such as a card name or identification number. 

Since the data-empowered test architecture 100 of the invention may support 
multiple cards for a given signal-type 178, the abstraction router 180 may have several 
abstraction handlers 182 for that given signal-type. The card-type property 184 retrieved 
from the hardware properties file 134 is used to select the correct abstraction handler 182a. 

As an example. Figure 14 illustrates the interaction of the Discrete Out 
abstraction router 180a and the NI-3243 abstraction handler 182a for an exemplary NI-3243 
vendor-supplied hardware driver 130a. 

The abstraction handler (AH) 182 performs the function of routing data and 
parameters to and from the vendor-supplied hardware drivers 130. The data-empowered test 
architecture 100 of the invention provides an abstraction handler 182 for each vendor driver 
to be accessed. These handlers 182 are the only place in the code of the data-empowered test 
architecture 100 where calls to specific hardware are made. The abstraction handlers 182 
determine which channel, relay or address to access fi-om information stored in the hardware 
properties file 152, as illustrated in Figure 14. Any data or properties sent to the hardware via 
the abstraction handler 182 is obtained from the test properties control file 152. Figure 14 
also illustrates an exemplary interaction between the NI-3243 abstraction handler 182a and 
the NI-3243 vendor driver 130a for the SETaction 1 1 5a. 

The abstraction handlers 182 are either built into the test framework 102 
software code, or they are self-contained Dynamic Link Libraries (DLLs) that dynamically 
link into data-empowered test architecture 100. The self-contained Dynamic Link Libraries 
enable abstraction handlers 182 to be added by project development groups without changes 
to the source code of the data-empowered test architecture 100. 



Attorney Docket No.: H0003463 



35 



Figure 15 is a block diagram tliat summarizes by example steps of the test 
procedure of the data-empowered test architecture 100 of the invention for interfacing with 
low-level vendor-supplied hardware drivers 130. The example illustrated in Figure 15 shows 
a variety of test procedure steps using the Out action 1 1 5 and how the test procedure steps are 
5 processed by the data-empowered test architecture 100 of the invention. 

As test procedure steps are processed by the test procedure interpreter 124 of 
the invention, the action 1 15 specified by the procedure step is activated in the form of an 
action dispatcher 126. The action dispatcher 126 determines the tester resource signal-type 
178 to be used to complete the procedure step by reading the tester resource 176 signal-type 
10 from the hardware properties control file 134, and launches the appropriate signal-type 

abstraction router 180. The abstraction router 180 determines the card-type 184 for executing 
the procedure step by reading the tester resource card-type 184 from the hardware properties 
file 134, and calls the appropriate abstraction handler 182. The abstraction handler 182 then 
interfaces with an appropriate low-level vendor-supplied hardware driver 130. 
1 5 The data-empowered test architecture 100 of the invention is estimated to be 

capable of performing approximately ninety-percent of current testing without modifications. 
The data-empowered test architecture 100 supports the remainder ten-percent by 
accommodating additional "helper" fonctions and provides for insertion of traditional tests 
using the Perform action, shown in Figure 1 1 
20 Figure 16 illustrates an exemplary "helper^' function 186 as a data conversion 

function, such as a function converting a feet measurement value to an ARINC 429 value 
prior to transmission. According to the exemplary "helper" conversion function 186 in Figure 
16, Out and In action dispatchers 126e and 126g automatically check the test properties file 
152 for helper fiinctions. These "helper" functions 186 are added to the code of the 
25 data-empowered test architecture 100 of the invention if they can logically be used across test 
projects. 

The data-empowered test architecture 100 of the invention is designed to 
support testing of multiple UUTs either in an ATP or in a Highly Accelerated Stress 
Screening (HASS) environment. Such conditions cause the data-empowered test architecture 
30 100 to have a robust operating system capable of preemptive multi-tasking and 

multi-threading. Operating systems that are less than robust or only emulate multitastong 
functionality are not believed to be suitable. Operating systems that suffer limited availability 
of drivers for the tester hardware also are believed to be unsuitable. A preferred choice of 
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15 



operating s,s.«n is ™«re so .ha. a iarg. number of drivers are available for ,he .ester 
ZL:aL.beop«a.i.s,s.e.is,esss.^.e....^^^^^ 
preferred operating system permLs easy .0 access fte World w.de 
nuisance passport-type promp.s. ™^^edtesl 
P^gramming language for use in praoticng the data-empowered tes. 
„c.,itecture,OOof.be>nventionisse,eotedaspr„vidinsco„tr„.ov.«^^^^^^ 

rLn.alesoftHedata-e.poweredtestarcbitecture.OOoftbe.nve„^^^^^^ 

virtually no test program coding, which moots the development ^me-savngs of a 
commercially available graphical programming language 

The data-empowered test archite«ure .00 of the invenfon ,s a radtctJ 

• - , The data-empowered test architecture 100 for the first tune 

:r»retrd:rw—:i— 

;r«. activity. This is in sharp contra, to prior art pt^cesses where test programs are 
2^ o mel schedules and are never revisited except to fix bugs or to suppo« new LRU 
;oI«L.uresThus,the prior art operatesina-release and forget, mode wherem poorly 

.esignedtests^era^n^^^^ 

, *e data- empowered architecture ,00 ofthe invention. New or improved tests are qutcHy 
*^2irthetestproperties«e,5.as.heyaredeve.oped.AI.testprogramsacoo^.ng» 

.rllmpowered tes. architecbtre 100 of the invention can also quickly mcorpora^e 
the data empowe ^.,„,h. daw-empowered test architecture 100 

additional features and enhancements made to the data empowe 

, A.estprope„iesdatabase.88(sho«ninFigure6)isop.ionallyprovided 
' ^arate.omthedat:.empowered.estarehitecture,OOpr.ect..amewor.an..^^ 

.1 p.pe«ies file 1 52 for storing all tests and tes. da.a for all ^-'-'^^-^'^^l 

archIelretestp,»iects.Theoptionaltestpropertiesdatab.e,S8perm„^^^^^^^^ 

. , ,„„he LRU Dn>duc< designer B, en.er.es. data and properties. The test propemes 

,0 r,:ri™asthe.es.pi^ 

lOO of .he invention, is generated as a database report. 

An initial embodiment of the d«a-empow«ed test arehttec^re 00 of the 
i„vention may not use a test properties database. Rather, Comma Separated Value (CSV) 



Patent ADolication „„^^„ 
Attorney Docket No.. H0003463 

37 



10 



fi,es provide .he data for .his Wa. emhodi-nen.. PHor .o crearing a .es. propem « d^^ 
,S8 .he eo„«o. files 108 are p«>vided in XML spreadshee. forma, and are edned w. h 
pro^rieurv software .ool. An al,ema.ive embodimen. of inveniion u.ilizes .he op«ona 
rZpL <.a.ahase ISS and a server-side appUe«ion .o creare .he XML sprea shee. files. 
The forma, of .he con^l files .OS is abs..ac,ed from .he ,e« program by 
Componen. Objec. Model (COM) oomponenls so .ha, as *ese files are upda.ed .o XML 
forma., only .he COM components will require updating. 

One inhial embodimen. of .he da.a-empowe.ed .es. archneehrre lOO of .he 
invention uses Comma Separa.ed Value <CSV) files as .he da.a souree. 0,her emM<Umen.s 
of .he dau-empoweredres. archi.ec.ure ,00 of .he inveniion provide ,es, properties files 152 
„f.hedauempow ^ML file format Addhion of XML suppor. 

and hardware properties file 134 .ha. supponu.e 

does no. affee. exis.ing .es. programs crea.ed ac«,rding .0 .he da.a-empowered .e^ 
arehi.ecn.re 100 of .he invention since CSV coniinues .o be supposed and ^"^^^ 
sources are abstia^ed from .he .es. program via .he hardware propert.es reader .32 and .es. 
properties reader ,36 c»mpo„e„.s of .he software components module 106 

-n,e data-empowered .es. archi.ecm.e 100 of a,e inven.,on ,s des.gned as a 
ftamewor. for all test prt.ject.. Bec«.se of ti.is. one or .wo sys.em software engin^rs sWled 
in an appropriale programming lan^e can and should perform maintenance o *e 
framellclnfac., all shared code wi.hinti,eda.a-empower^.e,.arch,.e«u.,^^^^ 

0 invemion. including .he code of .he .es. framework module .02. .es. executive modu^ 1^ 
1 software componenrs module 106. can and should ^ eontioUed and mam.a,ned by .h.s 
Lwaresystem group. This group can and should alsoberesponsiblefor^^ 

^ program engineers in the use of .he da«-empowered .es. arch,.e«ure .00 of *e 
invel! This group can and should also continue .o upgrade .he da«-empowered es. 
,5 ::L.relOObya«ingfeati.resasappropHa.eandop.io„al,yass,s.si.crea..ngh.dware 

abstiac.inter6eemodules,28whennewhardwareisaddedtoates.p,a.form. 

The individual »s. program designer, or .he LRU produc. des,gner, can 
pe,form.es.p,»gramereationbycrea.ing.heco«rolfi,eslOSof.heda.a-empo^^^^^ 

archHeCure ,00. Tes. prog^ e,ea,ion does no. require coding expenence or knowledge 
30 However, if some projecr-specific coding is .o be perfonned. ti« .e. program des,gn„ 
should be skilled in .he app.opri..e prof^mg language or have ac^s «- help w,.h 
project-specific coding needs. 
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The method of the invention as described herein is optionally embodied in a 
computer program product stored on a computer-usable medium, the computer-usable 
medium having computer-readable code embodied therein for configuring a computer, t 
computer program product including computer-readable code configured to cause a computer 
to generate a plurality of the test actions 1 15; computer-readable code configured to cause the 
computer to access the plurality of the actions 115; computer-readable code configured to 
cause the computer to identify a test equipment hardware resources 176 associated with a 
current one of the action 1 1 5; and computer-readable code configured to cause the computer 
to interface with an external hardware driver 130 as a fimction of the test equipmem hardware 
resources 176 associated with the current action 115. 

According to one embodiment of the invention, the computer-readable code of 
the computer product that is configured to cause a computer to interface with the external 
hardware driver 130 also includes computer-readable code configured to cause a computer to 
do all of the following: determine the signal type 178 corresponding to the identified test 
equipment hardware resource 176; access as a fimction of the signal type 178 one of the 
external control files 108 having test equipment hardware resource card-type 184 information 
contained therein, i.e., the hardware prx)perties control file 134; and determine the test 
equipment hardware resource card-type 184 information as a fimction of the card-type 
identifier 185. 

The computer-readable code of the computer product that is configured to 
cause the computer to generate a plurality of test actions 115 includes computer-readable 
code configured to cause a computer to receive one or more of the test ID numbers 159 fi-om 
a stored Ust of the test ID numbers 159, and to generate the plurality of test actions 115 as a 
fimction of the received test ID numbers 159. 

The computer-readable code of the computer product also includes 
computer-readable code configured to cause the computer to perform the pass/fail analysis 
and to generate one or more of the test reports 110. 

The computer-readable code of the computer product also includes 
computer-readable code stored in one or more of the software components 106 and 
configured to cause the computer to interface between the computer-readable code 
configured to cause it to generate the plurality of test actions 1 15 and the computer-readable 
code configured to cause the computer to access the plurality of test actions 115. 
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While the preferred embodiment of the invention has been illustrated and 
described, it will be appreciated that various changes can be made therein without departing 
from the spirit and scope of the invention. 



